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Presence and Instant Messaging Peering Use Cases 
Status of This Memo 


This memo provides information for the Internet community. It does 
not specify an Internet standard of any kind. Distribution of this 
memo is unlimited. 


Abstract 


This document describes several use cases of peering of non-VoIP 
(Voice over IP) services between two or more Service Providers. 
These Service Providers create a peering relationship between 
themselves, thus enabling their users to collaborate with users on 
the other Service Provider network. The target of this document is 
to drive requirements for peering between domains that provide the 
non-VoIP based collaboration services with presence and, in 
particular, Instant Messaging (IM). 
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Introduction 


This document uses the terminology as defined in [1] unless otherwise 
stated. 


Real Time Collaboration (RTC) services have become as prevalent and 
essential for users on the Internet as email. While RTC services can 
be implemented directly by users in a point-to-point fashion, they 
are often provided for, or on behalf of, a Peer Network of users 
within an administrative domain. As the use of these services grows, 
users increasingly have the need to communicate with users not only 
within their own Peer Network but with those in other Peer Networks 
as well (similar to the old Public Switched Telephony Network (PSTN) 
that enabled global reachability). In practice, each Peer Network is 
controlled by some domain, and so there is a need to provide for 
easier establishment of connectivity between Peer Networks and for 
the management of the relationships between the Peer Networks. This 
document describes a set of use cases that describe how peering 
between Peer Networks may be used in non-VoIP RTC services. The use 
cases are intended to help in identifying and capturing requirements 
that will guide and then enable a secure and easier peering between 
Peer Networks that provide non-VoIP RTC services. The use cases for 
the VoIP RTC services are described in [2]. 


Note that this document does not define requirements for a new 
protocol or for protocol extensions. It captures the way that 
presence and Instant Messaging are currently used within enterprises 
and operator domains. 


Use Cases 
1. Simple Interdomain Subscription 


Assume two Peer Networks, Peer Network A and Peer Network B. User 
Alice@example.com (hosted in Peer Network A) wants to subscribe to 
user Bob@example.net (hosted in Peer Network B) and get his presence 
information. In order to do so, Alice@example.com could connect 
directly to example.net and subscribe to Bob’s presence information. 
However, Peer Network B is willing to accept subscriptions and route 
IMs only when they are coming from its users or from other Peer 
Networks that Peer Network B trusts. 


In reality, what will happen is Peer Network A will connect to Peer 
Network B and send Alice’s subscription to Bob via Peer Network B. 
When Peer Network B has new information on Bob, it will send 
notifications to Peer Network A, which will pass them to Alice. 
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List-Based Interdomain Subscription 


This is similar to the simple interdomain subscription use case, 
except in this case Alice subscribes to a Uniform Resource Identifier 
(URI) [8] that represents a list of users in Peer Network B [9] [3]. 


There are several types of lists that Alice may subscribe to: 


(0) 


Houri, 


Personal group - a list that is created and maintained by Alice 
and includes Alice’s watch list. 


Public group - a list that is created and maintained by an 
administrator. Public groups usually contain a list of specific 
people that have some common characteristic, e.g., support group 
of a company. 


Ad-hoc group - a list that is short lived and is usually created 
in the context of some activity that Alice is doing. An ad-hoc 
group may be created by Alice or by some application. Typical 
examples may be the list of people that participate with Alice in 
a conference or a game. 


Authorization Migration 


If many users from one Peer Network watch presentities [6] in 
another Peer Network, it may be possible that many watchers [6] 
from one Peer Network will subscribe to the same user in the other 
Peer Network. However, due to privacy constraints that enable a 
user to provide different presence documents to different 
watchers, each Peer Network will have to send multiple copies of 
the watched-presence document. The need to send multiple copies 
between the Peer Networks is very inefficient and causes redundant 
traffic between the Peer Networks. 


In order to make the subscription between Peer Networks more 
efficient there needs to be a way to enable Peer Networks to agree 
to share privacy information between them. This will enable 
sending a single copy (the full copy) of the presence document of 
the watched user and letting the receiving Peer Network be 
responsible for sending the right values to the right watchers 
according to the delegated privacy policies of the watched users. 


Instead of sharing the watched user’s privacy policies between the 
Peer Networks, it is also possible to send different copies of the 
presence document with a list of the watchers the presence 
document is intended for. For example, if there is a set of 
watchers in one Peer Network that may see the location of the 
presentity and another set of users in the same Peer Network that 
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may not see the location information, two presence documents will 
be sent--each associated with a list of watchers that should 
receive it. One presence document will contain the location 
information and will be associated with a list of users that may 
see it, and the other presence document will not contain the 
location information and will be associated with a list of users 
that may not see the location information. See [11]. 


2.4. Pager Mode IM 


In this use case, a user from one Peer Network sends a pager mode 
[7] IM to a user on another Peer Network. 


2.5. Session Based IM 


In this use case, a user from one Peer Network creates a Message 
Session Relay Protocol (MSRP) [10] session with a user from 
another Peer Network. 


2.6. Other Services 


In addition to VoIP sessions, which are out of scope for this 

document, only presence and IM have been ratified as RFCs. In 
addition to presence and IM, there are many other services that 
are being standardized or that may be implemented using minimal 


extensions to existing standards. These include: 

o N-way chat - enable a multi-participant textual chat that will 
include users from multiple Peer Networks. See [4] for more 
details. 

o File transfer - send files from a user in one Peer Network to a 
user in another Peer Network. See [5] for more details. 


o Document sharing - sharing and editing a document between users in 
different Peer Networks. 


Note: Document sharing is mentioned in this document only for 
completeness of use cases. It is not being standardized by the 
IETF and will not be included in the requirements document that 
will result from this document. 


The list above is of course not exhaustive, as new developments in 
the world of non-VoIP RIC will surface new services. Enabling 
peering between networks for some of the services will create a basis 
for enabling peering for future services also. 
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2.7. Federation and Clearing House 


A federation as defined in [1] enables peering between multiple Peer 
Networks. A federation may be implemented by means of a central 
service providing a hub for the Peer Networks or, alternatively, Peer 
Networks may connect to each other in a peer-to-peer fashion. One of 
the most important services that this hub type of federation should 
provide is authorized interconnection that enables each Peering 
Network to securely identify other Peering Networks. Other services 
that might be provided include an N-way chat server, lawful 
interception, logging, and more. This hub type of federation is also 
known as a "Clearing House". 


As non-VoIP services are usually text-based and consume less 
bandwidth, they may benefit from having a central service that will 
do central services such as logging for them. For example, instead 
of requiring each Peer Network to log all messages that are being 
sent to the other Peer-Network, this service can be done by the 
Clearing House. 


3. Security Considerations 


When Peer Network A peers with Peer Network B, there are several 
security issues for which the administrator of each Peer Network will 
need mechanisms to verify: 


o All communication channels between Peer Networks and between each 
Peer Network and the Clearing House have their authenticity and 
confidentiality protected. 


o The other Peer Network is really the Peering Network that it 
claims to be. 


o The other Peer Network is secure and trustworthy, such that 
information that is passed to it will not reach a third party. 
This includes information about specific users as well as 
information about the authorization policies associated with user 
information. 


o The other Peer Network is secure and trustworthy, such that it 
will not modify or falsify data that it presents to its users 
except as required by the authorization policy provided. 


o If there is a third party (e.g., a Clearing House) involved in the 


connection between the two Peering Networks that element is also 
secure. 
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The same issues of security are even more important from the point of 
view of the users of the Peer Networks. Users will be concerned 
about how their privacy is being adhered to when their presence 
information is sent to the other Peer Network. Users today are 
concerned about providing their email address to a third party when 
they register to a domain; presence contains much more sensitive 
information, and the concern of users here will be even greater. 


The privacy issue is even harder when we take into account that, in 
order to enable scalable peering between big Peer Networks, there are 
some optimizations that may require migration of the privacy 
definitions of users between Peer Network (see Section 2.3). We can 
imagine the fiasco that would ensue if a user of one Peer Network 
were able to see the privacy information and learn he/she is listed 
in the block list of a close friend. 


This document discusses use cases for peering between Peer Networks. 
It is out of the scope of this document to provide solutions for 
security. Nevertheless, it is obvious that the protocols that will 
enable the use cases described here will have to provide for the 
security considerations also described here. 
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